Network technologies such as the Internet have provided users and other entities with virtually unlimited access to remote systems and associated applications. This type of access in many cases has become a complex maze of processes that is often offloaded to third-party systems to manage. Application heterogeneity has increased exponentially, and rapid growth has forced enterprises to develop and deploy applications ever faster—even at the expense of integration and ease of administration. Historically, enterprises generally only had to consider these issues at an internal level. In many situations however, these enterprises now have to grant external access to employees, supply chain partners, contractors and customers. Organizations that employ third-party service providers (application, network or otherwise) generally, manage users and access rights across both their internal systems and the systems run by service providers. Moreover, as new applications are developed to meet these challenges, application development, testing and deployment within and/or outside an organization has become increasingly more complicated and expensive.
Applications are often developed and described as one or more services that perform a desired computing function for a user or a group of users, wherein the services are often deployed across many components and systems. As these services are developed, various types of feature, development, testing, operations and/or other type teams or staff are often involved during portions of service development and during the ultimate installation/operation of the services in an operational system. When services are developed in a feature team, for example, the focus is generally placed on the features and associated functionality of the services. Many times, when the services are turned over to an operations team or other type team for integration and deployment, only written documents are included relating to the previous team's deployment architecture which may have little or no relevance to the subsequent team's needs. Thus, the process often fails for a large deployment that involves multiple components, complicated inter-machine coordination, and according to diverse deployment requirements of various teams. Based upon requirements and complexities associated with larger deployments, many problems can be encountered.
One such problem relates to deployment documents that are substantially static in nature and based on a topology defined by a previous team of developers. As an example, if an operations team were to receive deployment instructions from the feature team, the operations team would generally have to perform extrapolation of the feature team's deployment topology in order to deploy services in a topology suitable for the operations team. Such extrapolation is generally error-prone and therefore the reliability for future or different deployments suffers. As a result, deployment in a production environment often fails even though developers and testers claim successful project completion before passing the services to a subsequent team.
Another problem typically encountered relates to various teams utilizing different deployment techniques such as to develop competing script files and packages for service deployment. This can introduce exponential complexity into service development when an operations staff, for example, manages services developed by multiple feature or development teams. Furthermore, integration of services from different feature teams is often done in an ad-hoc manner without substantial planning involved for the overall process from development to operation of the service. Therefore, the lack of a consistent integration scheme often introduces redundancy, inconsistency and complexity, thereby increasing the cost of deployment. Such complexity and inconsistency generally can lead to high operating costs and a low degree of service manageability.